It is not uncommon for the owner or administrator of a server to want to determine the accumulated change in the number of events processed by the server in a given time period. For example, an owner of an email service or the owner of a web site may want to determine the number of messages processed by each of its servers over a specific time period, and whether the number increases or decreases, and by how much, over extended time. This information is useful, for example, to facilitate load balancing of the servers and/or o determine the effectiveness of an advertisement on a web site.
This information can be determined by calculating the total (peak) number of events over a period of time and tracking the accumulated peaks. For example, the total number of events (e.g., action taken by a processor, messages processed) since a service started can be calculated. Each time the service is restarted, the total number of events (peak value) is reset to zero. The peak values can then be used to determine the accumulated change in the number of processed events. A typical approach to determining the peak values is to iterate through all data points by time and find the points that have an adjacent neighboring point with a lesser value. This approach can be slow and leads to low performance, especially if the number of data points and number of servers is large. Also, since the data is often saved in a data base, this search approach often leads to low performance query algorithms when the data set is large. Further, the data must be sorted by time before the search. Another common database query technique to solve this issue is to sort the data and add an order ID field. The order ID filed can then be used to group the adjacent points together and compare their values. This approach, however, requires extra space to save the temporary data. It also compares the value of every adjacent data point. This does not scale well for large data sets.